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ABSTRACT 



A reply descriptor for transmission over an I/O message 
passing medium in response to a corresponding request 
message, the descriptor comprises at least one indication 
field that can function as a 'flag* to identify its type, and a 
content field; whereby a reply message is generated only if 
at least one predefined condition is not met and the content 
field will, accordingly, comprise information of that reply 
message's storage location. The content field to comprise 
data copied from the I/O lequest message if each predefined 
condition is met. A method of responding over an I/O 
message passing medium to a request message comprising 
the steps of: generating a reply message to the request 
message only if at least one predefined condition is not met; 
generating a reply descriptor having at least one indication 
field and a content field; whereby the content field comprises 
information of the reply message's storage location if so 
generated. Also, a program code on a computer readable 
storage medium comprising: a first program sub-code for 
generating a reply message to a corresponding I/O request 
message only if at least one predefined condition is not met. 
The first program sub-code comprising instructions for 
generating a reply descriptor having at least one indication 
field and a content field that comprises information of the 
reply message's storage location if said reply message is so 
generated. 

25 Claims, 8 Drawing Sheets 
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METHOD OF RESPONDING TO I/O software layers. Tbc header and payload parts reside within 

REQUEST AND ASSOCIATED REPLY a physically-contiguous buffer called the message frame 

DESCRIPTOR buffer (such as is shown in FIGS. 3-19 of the ^O 

Specification). 

5 1,0 messages fall into two basic categories: (1) request 

BACKGROUND OF THE INVENTION messages initiate activity at the destination (a request may 

In general, the present invention relates to communicating contain multiple transactions of the same type); and (2) reply 
message information, or data, over message passing messages return status information concerning one or more 
interface^) between program modules, such as a target requests. According to 1^0 convention, a reply message is 
peripheral device module and an operating system (OS) 10 generated and sent Cor every request (see I 2 0 Specification 
module within an I/O system, whether the modules are sections 6.1.2 and 6.4.4), regardless of whether the request 
executed on the same or different digital computer proces- was completed without error (see section 6.4.4.2.1 of I 2 0). 
sors and whether utilizing different operating systems. Of I 2 0 convention classifies all messages, each class has a 
particular interest is the message reply portion of the com- format for request messages and a protocol for generating 
municalion between I/O system modules to, eventually, send 15 and transmitting reply messages for that class. For example, 
status information back to the caller (e.g., an operating 'utility messages' are common to all message classes, and 
system) that issued the original command, regardless of the messages specific to a particular message class are 'base 
specific communications protocol and interface technology class messages'. According to the I 2 0 Specification, 
employed. More particularly, the invention relates to a inbound and outbound queues are reserved for each I/O 
unique method of responding over an I/O message passing 20 platform (referred to therein as "IOP" — see FIGS. 2A and 
medium to a corresponding request message, by way of an 2B schematically outlining the relationship between a host 
associated novel reply descriptor transmitted in response platform, an I0P1, and I0P2). Note that the I 2 0 Spccifica- 
tbereto. uon uses IOP synonymously with an 'I/O processor entity* 

Wiihin an I/O system, typical computer hardware includes dedicated to processing I/O transactions (consisting of 
a host system entity connected to communicate with one or 25 processor, memory, and I/O devices). The inbound queue of 
more I/O devices. The trend in development of I/O system an IOP receives messages from all other platforms, includ- 
architecture is to utilize a split driver model, see FIG. 1, as ing the host system, and the outbound queue of each IOP 
explained more-folly in a Version 2.0 of the "Intelligent I/O collectively function as an input queue for the host system. 
Architecture Specification" dated Feb. 11, 1999 (herein Thus, each IOP provides support for passing messages 
referred to as simply U I 2 0 Specification"), the written work 30 without requiring additional host system hardware. Once 
product of the collaborative effort of several commercial lOPs establish connection, the program modules at each end 
entities including the applicant hereof. Within the split of the connection can send and receive messages (generally 
driver model two bask software modules are defined, each in an asynchronous fashion as non-blocking by nature). In 
of which can execute on different physical processors and the specific case of an SCSI Controller, for example, it is the 
within different operating environments: (1) an OS-specific 35 SCSI hardware device module that detects and registers 
module (OSM) which provides an interface to the operating devices connected to the SCSI bus — and these devices are 
system (OS); and (2) a hardware device module (HDM) accessible through messages passed through toe SCSI hard- 
which provides an interface to each 1/0 adapter and corre- ware device module. 

spending device. These two basic modules intercommuni- According to I a 0 section 6.1.2, reply messages fall into 
cale via a logical "messaging layer" comprised qf a network 40 two general categories (as identified by the REPLY bit in the 
of Messengerlnstances (depicted in FIGS. 2-3 of the l z O message header's MessageFlags field): "failed" messages 
Specification) as illustrated herein in FIG. 1 over which and "processed" messages. Failed messages are those that 
request messages to I/O devices and completion reply mes- cannot be processed (including messages that cannot be 
sages are transmitted to effect commands from the operating delivered or contain invalid or missing data). A request 
system rather than having the hosi/OSM directly read and 45 message "fails" when the message layer cannot deliver the 
write from and to each I/O device register. The split driver message or the target device does not understand tbc format 
model allows for expansion of the I/O system through of the request (e.g., unknown message version). Section 
software development, independent of both device hardware 6.1.2.1 further distinguishes a failed message from one that 
and the operating system. is processed but is unable to be successfully completed due 

I. Conventional Way to Respond to Requests per I a O Sped- 50 to "error": The inability of a device driver module (DDM) 
ficatioo to perform or cany out the request is referred to as an 

Additional layers of stackable drivers beyond the basic "error". Thus, a successfully completed request is one that is 
OSM and HDM can be logically defined as has been done processed without error. Note that in I 2 0, the acronym DDM 
in the IjO Specification to provide additional functionality is often used generically in place of specifying whether the 
between the two basic program modules. The stacking of 55 module is a hardware device module (HDM) or an interme* 
drivers increases the request and reply message load of the diate service module (ISM). 

system, in turn decreasing its speed/performance. For Section 3.4.1.2.2 of 1 2 0 specifies the template for a 
example when operating within IaO, on tbe order of 28,000 "normal single transaction reply message" as shown in 
I/O messages are transmitted per second. The I 2 0 Specif! - FIGS. 3-23; and section 3.4.3.2 identifies a ''multiple trans- 
cation explains in Section 3.4.1 ("Message Structure and 60 action reply message" model (wherein one or more success- 
Definitions"), messages are data structures that contain a ful transactions may be combined into one reply message, 
fixed-size header containing device address and payload see section 6.4.4.2.2 of I a O). 

description and, immediately following, a variable-size pay- As shown and explained in more detail in Chapter 2 of the 
load containing all additional information associated with I 3 0 Specification (pages 2-19 through 2-22), whether 
the message. If the payload refers to memory, a scatter- 65 request messages are sent from tbe host system to a bard- 
gather list (SGL) is included in a formal understandable by ware device module or are sent peer-to-peer (from one 
tbe originator, the target, the transport, and any intermediate hardware device module to another), all reply messages built 
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include the Initiator Address, Target Address, and the Ini- devices, Hie SH-2 working draft states that a SCSI bus 

tiator Context field from the request message. Once the reply consists of all the conductors and connectors required to 

message is built, lhe hardware device module calls a respec- attain signal line continuity between every driver, receiver, 

tive message service. The sending entity allocates a reply and terminator for each signal. In operation, a SCSI bus is 

message frame, copies lhe reply message into the frame and 5 a bidirectional, muliimaster bus which can accommodate 

places/writes the frame's address in the appropriate message peer to peer communications among multiple computer 

queue 1,0 FIGS. 2-13 diagrams the flow of events for its processing units (CPUs) and multiple peripheral devices. A 

conventional process of sending request and reply messages SCSI device is one that contains at least one SCSI port and 

fl„0 Specification explanation reproduced below, for the means to conned the drivers and receivers to the bus. 

referenceV 10 A SCSI primary bus is one that provides for and carries 

« — « . i/n, „m„4 8-bit or 16-bil data transfer. ASCSI secondary bus carries an 

LTTmopcraUng system issues an ™j^st. Jjgj" ^ ^ b ^ ma ^ whcD ^ ^ 

2. The OSM (Operating System Module) accepts toe ^ fi . fa pr0 vides for a 324>h data transfer 
request and translates it into a message addressed to toe (although the latter is not, yet, widely used). SCSI 
DDM G 2 0 uses toe acronym DDM genetically for tf m ^ sagaM to a bus via 8-bit, 16-bil, or 32-bU 
hardware device module, HDM, or intermediate ser- ^ d SCSI paja Ucl interface devices may be 
vice module, ISM). The Initiator Context field is set to £ lcmcnled ^ 50, fig, or 80 pin connectors (whether 
indicate the message handler for the reply.The OSM shielded or unshielded. As is known, a typical data transfer 
has the option to place a pointer to the OS I/O request 0 ~ Jration ovcr a SCSI bus between a SCSI controller (or 
in the message's transaction context field. M „ tat adajllGr ») Seated in a host computer system, to a target 

3. The OSM invokes the communication layer to deliver device (such as a disk drive) has seven SCSI "phases": (1) 
the message. ARBITRATION, (2) SELECTION, (3) RESELECTION, 

4. The host's Messengerlnstance (a collection of services (4) COMMAND, (5) DATA, (6) STATUS and (7) MES- 
that support inftwliw'ng, configuring, and operating its SAGE. For example, during the COMMAND phase, a SCSI 
client modules, see FIGS. 2-3 of the laO Specification) 25 command is transferred from the host adapter to a^larget 
queues the message by copying it into a message frame (drive), and so on. Host adapter functional circuitry is 
buffer residing on the remote IOP. typically maintained on a host bus adapter (HBA) chip on a 

5 The IOP on toe other end posts 1he message to the printed circuit board structure referred to as a host adapter 
" DDM's event queue. board (HAB) for connection to a PC host via an expansion 

6. The DDM processes the request. , *° ST For Reference: Brief Background of Fibre Channel 

7. After processing the message and satisfying the request, *™ *~ KrracB - Dn 0 ^ 

the DDM buUds a reply, ^piesi die "S^nel is a newer interface technology (emerging 

and transaction context ^ fro* ^ «^ ^ fte Architecture (SSA) and IEEE 

reply, addresses the reply to ^ » ^ ^ of ^osfifrring data as fast and faster than an 

invokes the message service to send it to the originator ^ system ^ ov £ fiber optic cabling as well as 

of the request. copper transmission media. Fiber Channel-type host bus 

8. The 10P*s message service queues the reply by copying ada p teIS m installed into a host computer expansion slot 
it into a message frame buffisr residing at the host's ^ ^ SCS1 host bus adapters are installed. Fibre channel 
Messengerlnstance. ^ co^^ctions arc often associated with the term "loop" (from 

9. The IOP alerts the host's Messengerlnstance to the mc Jjam Ffi)re Channel arbitrated loop) rather than ''bus" 
message ready for delivery. ^ SCSI devices are connected). There are actually other 

10. The host's Messengerlnstance invokes the OSM's types of Fibre Channel connections, called "point to point" 
message handler with the reply. and "fabric" With fibre channel, communication between 

11. The OSM retrieves the pointer to the OS I/O request 45 hosts and devices does not have to be done directly. Instead, 
from the message's transaction context field to estab- users can employ hubs and switches between devices on the 
ksh the original request context and completes the OS Fibre Channel network. Hubs and switches can be used to 
I/O request create Fibre Channel "storage networks". Fibre Channel 

12. The driver returns the request to the OS. cabling can be copper (can be up to 30 meters in length) or 
II. For Reference: Brief Background of SCSI 5t> fiber optic (currently up to 10 Km). In addmon, 00 tormi- 

Tne widely-used small computer system interface (SCSI) nation is necessary for fibre channel as is required in SCSI, 

protocol was developed for industry groups, under the Fiber optic ports directly placed on a peripheral device allow 

American National Standards Institute (ANSI) and Interna- only for connections to fiber optic cabling. Commercially 

tional Standards Organization (ISO) guidelines, to provide available adapters exist that allow a S^I-compliant device 

an efficient peer-to-peer I/O bus. Devices that conform with 55 to be connected to a Fiber Channel loop, 

the mechanical, electrical, timing, and protocol requirements IV. Identification of New Method and Reply Descriptor 

(including the physical attributes of I/O buses used to The trend in I/O architecture development is toward 

interconnect computers and peripheral devices) of the SCSI stacking more layers of logical drivers and creating high 

parallel interface will inleropcrale. This allows several dif- performance systems, thus increasing the request and reply 

ferenl peripherals (hard disk drives, removable disk drives. 60 message overhead of the I/O system, which in turn decreases 

tape drives, CD-ROM drives, printers, scanners, optical system efficiency and performance. Therefore, a new usenU 

media drives, and so on) to be added at the same time to a method of responding to an I/O request message and asso- 

host computer without requiring roodificatioDs to the generic dated reply descriptor are needed to make messaging 

system hardware. The working draft of the SCSI Parallel between one or more hosts, one or more interconnected 
Interfece-2 Standard (SPI-2), as modified (Rev. 16, dated 65 devices, or any host and an interconnected device, more 

OcL 14, 1997), defines the cables, connectors, signals, efficient Without a reasonable, reliable, and cost-effective 

transceivers, and protocol used to interconnect SCSI solution at band for increasing I/O system performance, 
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computer hardware and software developers will find it very Briefly described, again, the invention includes a reply 

difficult to meet the demand for managing mom devices in descriptor for transmission over an I/O message passing 

ever-complex I/O environments. As anyone who depends on medium in response to a corresponding request message, 

computerized systems to accurately and efficiently perform The reply descriptor comprises at least one indication field 

selected tasks will readily understand: It is imperative that 5 that can function as a 'flag' to identify type of the reply 

valuable I/O messaging data be communicated in a reliable, descriptor, and a content field; whereby a reply message is 

efficient manner that reduces system I/O overhead by using generated only if at least one predefined condition is not met 

less system resources such as system memory, CPU and the content field will, accordingly, comprise information 

(computer processing unit) cycles, system bus resources, of that reply message's storage location. Also characterized 

and so on. 10 is a method of responding over an I/O message passing 

SUMMARY OF THE INVENTION medium, to a request message. The method comprises the 

, steps of: generating a reply message to the request message 

It is a primary object of this invention to provide a method Qnl % at Jeisl onc predefined condition is not met; gener- 

of responding over an I/O message passing medium, to a alfa a ly dcscriptor having a t least one indication field 

request message and to provide an associated reply descnp- J5 anrf a con|enl ficl(J . wbcreby the content field comprises 

tor for transmission over an I/O message passing medium in information of the reply message's storage location if it is so 

response to a corresponding request message. A reply mes- generated 

sage need only be generated if at least one predefined Further" characterized is a computer executable program 

condition is not met, the reply descriptor to include at least code Qn a co™^ readable storage medium. The program 

one indication field that identifies its type and a content field, M C0[fc compifecs; a fat program sub-code for generating a 

whereby the content field comprises information of the reply { message to a corresponding I/O request message only 

message's storage location (in the event so generated). It is ^ al leasl one predefined condition is cot met. The first 

a further object to provide computer executable program program sub-code comprising instructions for generating a 

code on a computer readable storage medium, having { descriptor having at least one indication field and a 

instructions for carrying out the novel method and general- ^ field lbal comprises information of the reply mes- 

ing the novel reply descriptor. sage's storage location if said reply message is so generated. 

The simple, efficient design of the invention allows the The content field to comprise data copied from the I/O 

innovative method* reply descriptor, and program code as request message if each predefined condition is met. 

contemplated hereby, to be tailored-to, readily installed, and Additional, further distinguishing associated features of 

run using currently-available processors, memory, commu- ^ fa rc piy descriptor, method, and program code of the 

nications protocol and interface types, as well as those invention win be readily appreciated as set forth herein, 

under, or contemplated for, development. Further, unlike the including the following novel features. The message passing 

conventions currently specified and in use, the unique medium over which reply descriptors may be transmitted 

method, reply descriptor, and program code of the invention may comprise one or more parallel, serial, and wireless bus, 

do not require that foil reply messages) be built, copied, 3J or ^ hyond thereof More-specifically, suitable buses 

read and processed for each and every request message include those operational with any of a variety of hardware 

processed. In the spirit of this unique design, a reply interface types such as SCSI (Small Computer System 

descriptor can be generated and then transmitted for a Interface), Fibre Channel, PCI (Peripheral Component 

corresponding request for any class of messages as will be Interconnect), PCJ-X, ISA (Industry Standard Architecture), 

further appreciated. 40 InfiniBand, IDE (Integrated Drive Electronics), USB 

Although the advantages of providing the flexible new (Universal Serial Bus), RS-232, EISA (Extended ISA), 

method, associated new reply descriptor, and program code, Local Bus, Micro Channel, and so on. Further, the message 

as described herein, will be more -fully appreciated in con- passing medium can utilize any number of communications 

nection with the full specification, certain advantages are protocols such as those identified as SCSI, ATM 

listed as follows: 45 (Asynchronous Transfer Mode), IFI (Intelligent Peripheral 

(a) System Cost Reduction and Process Simplification — Interface), HiPPl (High Performance Parallel Interface), IP 
For the vast majority of request/commands generated (Internet Protocol), InfiniBand, SSA (Serial Storage 
by an initiator which are successfully completed Architecture), IEEE P1394, and so on. Upon the writing of 
(processed without error), a full reply message need not the reply descriptor to a reply-post buffer, an interrupt (or 
be build, copied, and read as is conventionally done; 50 any suitable alert mechanism by which to signal a host that 
thus, reducing adapter CPU firmware cycles necessary a reply descriptor has been so written) can be transmitted for 
to manage queues, which in turn, requires less expen- a host-based driver to read the reply descriptor; and once so 
sive adapters to handle the reply overhead. Unlike read, the host-based driver can correlate the reply descriptor 
conventional protocol, this powerful novel method and with the request message and send a notification message 00 
associated reply descriptor allows one to simplify the 55 to an originating-caller (such as a host-based operating 
process to communicate I/O request completion. Sim- system). 

plifying the design reduces overall system costs, such If each such predefined condition is met, the indication 

as the cost Reducing system costs, in-turn reduces the field might further comprise a type field, and the content 

cost to perform important I/O messaging functions, field can comprise data copied from and unique to the 

(b) Design Flexibility and Versatility — The invention can 60 request message as generated by a host-based driver; but if 
accommodate many different message passing medium the reply message is so generated, it preferably comprises 
hardware interface types; a wide variety of communi- data regarding the predefined condition(s) not met The 
cations protocols and message templates; and a xnulti- content field might further have a receiving port identifier, 
rude of different types of I/O systems and devices. Also, especially in the event each such predefined condition 
Furthermore, many different computer platforms can 65 is met, the data unique to the request message can comprise 
readily use the more-flexible I/O reply solutions offered any of a number of identifiers such as: an address (whether 
by the instant invention. physical or virtual) to a storage space in a memory (which 
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could be a temporary-storage, e.g. a queue, or more- 
perraaneni storage, e.g. a message frame), an index value or 
offset lo a table, an index value or offset to a list, an index 
value or offset to a register, an index value or ofiset to a layer 
of hardware registers (slack), an index value or offset loan 5 
array, content-data associated with a hardware assisted 
CAM, and so oo. *Ib conserve computer resources, the alert 
signal may be transmitted to the host-based driver after a 
predetermined number of such reply descriptors have been 
generated. to 

In the event the reply message is so generated, the content 
field of the reply descriptor can comprise an address to an 
available reply frame buffer located in a host memory; this 
address having been removed from a plurality of addresses 
residing on a reply-free buffer, each such address to identify 15 
a location of a corresponding reply frame buffer. Once the 
reply descriptor has been read by a host-based driver, the 
host-based driver can be instructed to remove the reply 
descriptor from the reply-post buffer. 

BRIEF DESCRIPTION OF THE DRAWINGS 

For purposes of illustrating the flexibility of design and 
versatility of the innovative preferred method, associated 
reply descriptor, and program code, the invention will be 
more particularly described by referencing the accompany- 25 
ing drawing? of embodiments of the invention (in which like 
numerals designate like parts). The figures have been 
included to communicate the features of the invention by 
way of example, only, and axe in no way intended to unduly 
limit the disclosure hereof. 30 

FIG. 1 is a schematic depicting a conventional split driver 
model 10 as explained in the "Intelligent I/O Architecture 
Specification" Version 2.0 0 a O Specification). An 
OS-specific module (identified as "OSM" at 12) that pro- 
vides an interface to an operating system ("OS") and a 35 
hardware device module (identified as "HDM" at 14) that 
provides an interface to each I/O adapter and corresponding 
device, which intercommunicate via a logical "messaging 
layer" 16. 



30 



FIGS. 8A and 8B depict alternative request and reply 
message formats for, respectively, a SCSI I/O Request 
Message and a SCSI I/O Error Reply Message. 

DETAILED DESCRIPTION OF THE 
PREFERRED EMBODIMENTS 

Two basic types of preferred reply descriptors of the 
invention are depicted in FIGS. 3A and 3B. Turn, first, to the 
Address Reply Descriptor 30 shown in FIG. 3 A: It includes 
information 34 useful for identifying a storage location of 
the frame for a reply message generated in connection with 
an unsuccessful I/O and an address bit 32. 
Description of Fields Represented in the Address Reply 
Descriptor of FIG. 3A 



PbyilealAddfcaa Bits 1::3J of the pbyrical address of the reply meouge 
frtxne generated, for example by the I/O Controller. 
This is • SMFA (System Message Frame Address) 
thai has bees shifted right by 
one bit making room for the address bit 32. 
A The address bit 32 Is set to 1 to denote it is an 
Address Reply Descriptor (since u least 
one coannaud/eoaditioa wis not met, 
therefore uamecessb] t/O). 



FIG. 3B depicts another general type of reply descriptor, 
namely, a context reply descriptor 35 that includes data 
preferably comprising at least some portion or sub-portion 
of data copied from the corresponding request message to 
which descriptor 35 pertains. For reference, the field con- 
taining this data copied from the request message is labeled 
"Protocol Dependent" 38a As wiD be better appreciated in 
cotmectioo with FIGS. 4 and 5, the context reply descriptor 
mechanism is unique, especially in thai no reply message 
need accompany it in responding to an I/O request The 
fields labeled 32 and 37a collectively make up an indication 
field 36a encoded for an initial 'quick' identification of 
whether or not the descriptor is an address reply descriptor 



containing a pointer, or address, to a reply message (address 
FIGS. 2Aand 2B (reproduced from the Sjjecification 40 bit set to 1); and if the descriptor is not of an address type, 



for easy reference) schematically outline the relationship 
between conventional components of an I 2 0 segment (a host 
platform 20, an IOP1 at 22, and IOP2 at 24). 

FIG. 3Ais a schematic of the fields in a preferred general 
address reply descriptor of the invention. 

FIG. 3B is a schematic of the fields in a preferred general 
context reply descriptor of the invention. 

FIGS. 3C and 3D arc schematics of the fields in two 
special cases of a preferred context reply descriptor of the 
invention. 

FIG. 3E depicts the fields of an example "header" for a 
message. 

FIG. 3F depicts an example default reply message such as 
can be used to communicate certain selected details of any 
one or more predefined condition not met 

FIGS. 4 and 5 are schematics detailing selected message 
and data flow features of an I/O system designed to aid in 
carrying out a preferred method of the invention, including 
flow of a preferred reply descriptor of the invention. 

FIG. 6 depicts an example map of System Interface 
Registers through which a host can communicate with an 
IOC (I/O Controller) — preferably access to these registers is 
provided via memory and/or IO mapping. 

FIGS. 7A and 7B depict alternative message formats, 
specifically detailing fields of an example Config Request 
Message and associated Config Reply Message. 



45 



the specific type of context reply descriptor it is (for 
example, see Type Table below). 

Description of Fields Represented in the General Context 
Reply Descriptor of FIG. 3B 



Type 
Bits: 



50 



55 



Bit 1 Bit 0 Type 



The specific type of Context reply mei 
^Definition of type bits (Type Table): 



nge. 



0 


0 


SCSI Initiator mode Context Reply 


D 


a 


SCSI Target mode Context Reply 


1 


0 


Reserved 


1 


3 


Reserved 


A 




The Address bit-when uatng • Centex! reply mag. thu bit 






U met lo 0 (itnce there wi successful 






completion of the I/O request). 



When the IOC is a SCSI initiator, a context reply descrip- 
60 tor such as that in FIG. 3C may be used for replying to an 
I/O request message that has been processed without error. 
The receipt of the reply descriptor 40 as depicted, namely a 
SCSI Context Reply, by the host driver implies the success- 
ful completion of the I/O. In this example, the IOC has 
65 copied (digitally, or otherwise, duplicated) the MessageCon- 
text data directly from a corresponding request message to 
generate a content field (386) for the reply descriptor 40 
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which is put on a Reply Post buffer (such as either of the 
FIFO's shown in FIG. 4 al 77 and 87). The Type (37b) and 
A (32) sub-fields of indication field 36b, are set once the 
MessageContext of the request message has been copied. In 
this example as shown, bits 0::28 of the MessageContext can 
be used by the host driver in any particular way selected. 
Description of Fields Represented in the SCSI Initiator 
Context Reply Descriptor of FIG. 3C 



10 



-continued 



Type Specifies lype or mode of this Context 

reply message. 

A The Address bit, here it has been reset lo 0 (since 

there was successful completion of the I/O request), 
R Reserved bit 



10 



MesiageContexl A copy of the MessagcConLexl field, His 0:28, copied 

from that supplied by the boil in Lie request message. 
Type The specific type of Context Reply-Set to denote * 

SCSI initiator mode Context Reply. 
A The Address bit, reset to 0 (since there wu successful 

completion of the VO request as in tie case Cor general 

Context Reply 35), 



IS 



As mentioned above, two types of messages axe used to 
convey information within the I/O method and system of the 
invention: (1) request messages are created by the system to 
"request" an action by an IOC; and (2) reply messages are 
used by an IOC to send status information back to the 
system. Each message includes a message header (of any 
predefined size) and a payload. By way of example only, the 
message header 50 represented in FIG. 3E is the first 12 
bytes of each message frame and reserved and unused fields 
will have a value of 0 (zero). The header includes informa- 



The alternative reply descriptor 45 illustrated in FIO. 3D 
has more detailed information concerning origination and lion * uniquely identify the message, 



transmission of the corresponding request The specific 
information selected foe encoding in a context reply descrip- 
tor of the invention will depend upon, among other things, 
I/O architecture design factors. When the IOC is in "TAR- 
GET 1 mode and a SCSI command has been transmitted and 25 
received, the depicted SCSI Target Context Reply Descrip- 
tor 45 may be used to convey more specific information tb 
the host system. Here, indication field 36c is comprised of 
fields labeled Type (37c) and A (32) and the protocol 
dependent content field 38c includes valuable additional 
information as follows: 

Description of Fields Represented in the SCSI Target Con- 
text Reply Descriptor of FIG. 3D 

35 



Description of Fields Represented in the Message Header of 
FIG. 3E 



30 



Function Tbe format of tin; field is dependent on the ftinction 

Dependent being described. 

Reserved Function dependent. 

Function Tbe food ton number of this message. This number 

dc^ ratines the format of the rest of the message 
(and differentiate! each 
request message from tbe others). 
MessageFlags All reserved bits most have a selected value, such ts 0, 

unlest otherwise identified in specific messages. 
MeaaagcContext A value used to uniquely identify this message. 

Created by the host driver end not modified by tbe 
IOC This value can be copied and 
'returned* in the Context Reply, see FIO. 3B at 38b. 



HostZndex (43) This index it specified by tie bast to truck the I/O. 

IOCI ndex (42) Tbe index used by tie COC to trace tbis I/a This bit 
can be used to indicate on which port the initial 
command was received. 

Lnltiaiortndez (41) A 6-bU value Indicating which Initiator sent this 
command. For parallel SCSI systems tHs can be 
the actual initiator ID value. Fcr FCP systems, 
U's an index into a table of logged in Initiators. 



I/O reply messages are currently used in each instance a 
response lo an I/O request is transmitted hack to an OSM 
40 (operating system module). The table below describes a 
default reply message such as thai labeled 60 in FIG. 3F. 
Description of Fields Represented in the Default Reply 
Message of FIG. 3F 



lOCStatus 



I0CSTXTTJS_SU0CESS 

IQCSTimJSJuVVAUD^FUNCnON 

IOCSTXTUS_BUSY 

IOC^MTUS-JNVAlJD_SOL 

IOCSXATUS_MSG_JCFER_ERR0R 

tOCSWUSJATA_XFERJRROR 

IOCSTATOSJNSUITICI£NT_JLESOURCES 

IOCST)OTS_INVAlJD_JIELD 

IOCSTATUS_CONFIO_BAD^ACTION 

lOCSIXrUS_CONnG_BAD_TYPE 

IOCSTATUS_CONFlGjaAD_f , AQE 

IOCSnATOS_CONFIGJAD_DATA 

IOCSTATUS_CONnG_NO_DEFAUlJS 

IOCSTATUS_OONFIG_CANT_COMMrr 

IOCSTATUS_SCSURBCX?VERED_JBRROR 
rOCSTAR«_SCSUNVALIX)_PUS 
IOCSTATU S_SCS LJNVALI D^TARGEITD 
IOCSXATUS_SCSI_DEVICE_NOT_THERE 



Description 

Command coaipleted successfully from tbe IOC 
standpoint. 

Function not supported by tbe IOC 

Can not process tbe request at this time. 

SGE not supported or understood. 

System bus error detected during message transt 

System bus error detected during data transfer. 

The IOC has insufficient resources to process the 

request at this time 

A field in tie message baa an invalid value 
The action is not suppoited 
The configuration type ii not supported 
The ronflgTr** 1 ™ page is not supported 
Incorrect field setting within the configuration data 
Can not set default! for this page 
Non-votatDe memory not available or error while 
writing persistent data to non- volatile memory 
I/O operation completed successfully after retries 
Out of range Boa value in request message 
Out of range Ta/gctlD value in request message 
Selection time-out or device does not exist 
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tOCStalus 

IOCSTATUS_SCSLDA3A_OVERRUN 

rOCSTATUS_5CS]_DATA_UNDERRUN 

IOCSTATOS_SCSI_|0_PATA-.ERROR 

IOCSTATlJS_5CSI_PROrCXOL_ERROR 

IOCST/^TUS_SCSIJIASK w TBRMINATEO 

IOCSTATUS_SCSl_BUS_RESET 

IOCST/OTS_SCSUTASK_MGMT_RMLED 
ICXSTAnJS_TARGET_PRIORITY_IO 

IOCST>mJS_TARGBr_INVAUD_ - POKr 

lOCSIV«rUS_TARCErjNVAlID_IOCINDEX 

lOCSTATUS_TARGET_ABORTED 

rOCST/miSJTAROET_KO_C»NKECnON_ 
RETRYABLE 

ICK2STATUS_TARGET_NO_CONNECnON 

lOCSrTATUS_TAROET_FC-ABOKTED 

IOCSOTUS^JAROETJINVALIDJID 

IOCSTATUS_JI>VRGJ5T_FC_NODE_LCXK5E 
D_OUT 

[OCLoglnfo Should be logged fay the host driven 



Description 

SCSI device attempted to transfer more data than 

lbs amount specified by the byte count 

SCSI device transferred less data than the amount 

specified by the byte count 

I/O terminated because of unrecoverable bus 

parity or CRC error 

I/O terminated because of unrecoverable bus 
protocol error 

I/O terminated because of SCSI Task 
Management Request 

I/O terminated because of a Bus Reset unrelated 

to a SCSI task Management Request 

SCSI Task Management function foiled 

An I/O operation has been received that requires 

priority handling 

A command was directed to a port that does sot 
exist on this IOC 

The Target Host used an lodndex value that is 

invalid or not in use on the IOC 

Tbia is a reply lor an I/O Dr buffer that was 

aborted at the request of the hosL 

Uoable to communicate to the Initiator of this I/O. 

The host can retry this operation later. 

Unable to communicate to the Initiator of this I/O. 

This I/O can never be continued. 

This is a reply for an operation or buffer that was 

aborted at the request of the host 

The Target Boat attempted to send a request that 

frr«/-t»H t D_ID value that is not in use. 

This operation bea bean canceled because the 

destination node has togged us oul 



One can readily appreciate the many and various types through space from a transmitter to a receiver, or some 
kinds of events which could trigger tbe building of a reply combination thereof) whether local or physically remote, 
message according to the method and program code of the 35 For each data element, there can be many fields in the 
invention. An address reply (fcscriptor such as that depicted database that hold the data items. As basic units of storage, 
at 30 in FIG. 3A, is accordingly generated in order to locate a data element describes the logical unit of data (i.e„ the 
tbe reply message to which it points. It is only when al least logical definition of the field), fields arc the physical storage 
one condition is not met, indicating that the request was not units (typically one or more bytes in size), and data items are 
processed without error, that such a reply message is gen- 40 me mmvidual iristances of the data elements (i.e. f actual data 
erated for transmission over the I/O message passing stored in the field). Computer readable storage rnwhum/ 
medium. For example, occurrence of one or more of the media, as used herein, can be any data earner or recording 
following events, among others, could trigger the generation medium into, or onto, which information (such as data) can 
of a reply message: execution of any one command of the be read and copied, such as magnetic (diskettes, hard disks, 
request is not completed initially or after a selected number 45 Iomega Corporation's OT^/JAZ^/Oickl™ disks, tapes, 
of 'retrys', any one command of the request was made at an drums, core, thin-film, etc.), optic (CD-ROM, CD-E, CD-R, 
improper time, an allotted time for execution of any one CD-RW, DVD, and other devices whereby readout is with a 
command of the request was exceeded, unsuccessful data light-source and pholodetcctor), magneto-optic media 
transfer of any portion of tbe request message, quantity of (media for which optical properties can be changed by an 
data transferred exceeded byte count specifications, quantity so applied magnetic field— used in high end drives), and other 
of data transferred was less-than that required in byte count such devices. 

specifications, processor resources were insufficient to A slack is a set of hardware registers or a reserved a ™° UD * 
execute any one command of the request, a least one field of memory used for arithmetic calculations, keep track of 
of the request message included invalid data, at least one internal operations, etc. A CAM (Content Addressable 
value from tbe request message was out of range, data 55 Memory), also referred to as "associative storage", is storage 
transferred was insufficient to execute any command of the that can be accessed by comparing the content of the data 
request, hardware interface of the message passing medium stored in it rather than by addressing predetermined loca- 
was iDCompahT)le with the target device, communications tions. A buffer is any reserved segment of memory or 
protocol utilized by the message passing medium was accessible storage used to hold data during processing. A 
incompatible with the target device, an unrecoverable bus 60 host can be any computer or computerized device that acts 
parity error has occurred, a task management function has as a source of information or signals, including for example, 
failed, a host processor aborted the request message, a target a centralized mainframe that is a 'host* to its terminals, a 
device node has iogged-ofE, and so on. server that is 'host' to its clients, lo a desktop PC that is 

The following is provided by way of reference: A message 'host* to its peripherals, and in network architectures, a client 
is any sized set or subset of data generated for transmission 65 station that is a source of information to tbe network, 
over a communications/message passing medium (which As mentioned above, the message passing medium over 
can comprise cabling, alone, or can include transmission which reply descriptors may be transmitted may comprise 
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one or more parallel, serial, and wireless buses, or any 
hybrid thereof. More-spedfically, suitable buses include 
those operational with a variety of hardware interface types 
such as those identified as SCSI; Fibre Channel; PQ 
(Peripheral Component Interconnect — commonly used to 
provide a high-speed data path between the CPU and 
peripheral devices such as video, disk, network, etc.); PCI- 
X; ISA (Industry Standard Architecture — an expansion bus 
commonly used in PCs along with ISA buses); InfiniBand; 



(represented at 90) takes ownership/control of the 5MP 
within which each respective I/O request message resides. 
E. The IOC 90 reads the request message frame descriptors 
from the Request Post FIFO 75 and DMA*s (Direct 
Memory Access — whereby data is transferred from 
memory to memory without using the CPU) the request 
messages to a local message frame (here, * local' to the 

ioq. 



IDE (Integrated Drive Electronics— widely used to connect 10 F- Toe IOC 90 generates and sends the appropriate request 
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hard disks, CD-ROMs and tape drives to a PQ; RS-232 
(Recommended Standard -232 — an TIA/EIA standard for 
serial transmission between computers and peripheral 
devices such as modem, mouse, etc., that uses a 25-pin 
DB-2S or 9-pin DB-9 connector); USB (Universal Serial 
Bus— used for low-speed peripherals such as the keyboard, 
mouse, joystick, scanner, printer and telephony devices); 
EISA (Extended ISA); Local Bus; Micro Channel; and so 
on. 

The message passing medium can utilize any of a wide 20 
variety of suitable communications protocol such as SCSI; 
ATM (Asynchronous Transfer Mode — a network technol- 
ogy for both LANs, local area networks, and WANs, wide 
area networks); IPI (Intelligent Peripheral Interface-a high- 
speed hard disk interface used with minicomputers and 25 
main&ames that transfers data in the 10 to 25 MBytes/sec 
range); HiPPI (High Performance Parallel Interface— an 
ANSI-standard high-speed communications channel that 
uses a 32-bit or 64-bit cable and transmits at 100 or 200 
Mbytes/sec); IP (Internet Protocol-the IP part of the TCP/IP 30 
communications protocol); InfiniBand, SSA (Serial Storage 
Architecture); IEEE P1394 (sometimes referred to as 
"FireWire" — high-speed serial bus cornmunicadoos that 
allows for the connection of up to 63 devices); and so on. 

One can better appreciate the flexibility of the reply 35 
descriptor and message flow of the invention in connection 
with viewing FIG. 4 which, by way of example only, 
includes the novel intercommunication of two separate host 
drivers represented and labeled as #1 a 70 and #2 at 60. The 
transmission of information in the form of request and reply 40 
descriptors as well as request and reply messages throughout 
the I/O system represented can be accomplished through the 
use of, for example, a dual function in PQ (the logical 
separation of which is indicated by dashed line 85) and 
multiple service connections in InfiniBand. Steps detailing 45 
activity within a novel I/O system that can carry out a 
preferred method of the invention are summarized below in 
connection with corresponding data flow lines (labeled A 
through L in FIG. 4): 

A Each host driver 70, 80 initially receives an I/O request 
from an operating system (not shown, for simplicity). 

B. Each host driver allocates a system message frame (SMF) 
from a collection of frames such as those shown at 71 and 
81 which preferably resides in system/host memory, and 
builds an I/O request message within the SMF. Since, 
here, SMFs reside in host memory, the particular means 
by which allocation is carried out is the responsibility of 
the host driver, and can be one of any conventional SMF 
allocation method. 

C. Each host driver 70, 80 generates its own request message 60 
frame descriptor (represented at 73, 83) for each respec- 
tive I/O request message built by the host. 

D. Each host driver writes its respective request message 
frame descriptor 73, 83 to a request queue labeled Request 
Post FIFO at 75 (in this novel example, the Request Post 65 
FIFO 75 manages request message frame descriptors from 
both host drivers 70, 80). At this point the IOC 



50 



55 



messages to a target device based on the port type 
associated with the Bus and TargetlD fields of the request 
message. For an example of an I a O request message 
structure which can be accommodated according to the 
invention— see I a O Specification, section 3.4.1.2.1. 

G. The IOC 90 receives the reply information from the target 
device — concerning whether the original request was 
processed without error, and if not, an indication of which 
condition was not met (the latter generally only to occur 
in a small fraction of the cases, such as for example, if a 
driver or interconnection is faulty). 

H. If the I/O status is successful (request was processed 
without error) the IOC 90 writes data unique to the 
corresponding original request message, such as the Mes- 
sageContext field value (see FIG. 3C at 386) or other 
Protocol Dependent data (see FIG. 3B at 38a and FIG. 3D 
at 38c) to the respective reply queue (labeled 77, 87 Reply 
Post FIFO), in turn, causing an alert signal 10 be trans- 
mitted (e.g., a system interrupt is generated) letting the 
respective host driver 70, 80 know that a reply descriptor 
is in the Reply Post buffer 77, 87. At this point, the 
respective system/host driver (represented at 70, 80) 
regains ownership/control of the SMF within winch each 
respective I/O request message resides. 

I. If the I/O status is not successful (e.g., either the I/O 
request was not fully processed or it was processed but 
done so with an error, thus, the I/O request was not 
successfully completed), the IOC 90 removes an address- 
to an available reply message frame from the reply queue 
(labeled 78, 88 Reply Free FIFO). The IOC 90 then 
generates a reply message in the host based message 
frame and writes the physical address of the reply mes- 
sage frame, shifted to the appropriate bits, to the respec- 
tive reply queue (labeled 77, 87 Reply Post FIFO), in turn, 
causing a signal to be transmitted (e.g., a system interrupt 
is generated) informing the respective host driver 70, 80 
that a reply descriptor is in the Reply Post buffer 77, 87. 
At this point, the respective system/host driver 
(represented at 70, 80) regains ownership/control of the 
SMF within which each respective I/O request message 
resides. 

J. The system/host driver 70, 80 receives the respective 
interrupt (or other suitable signal) and reads the Reply 
Post FIFO buffer 77, 87 to get the content field 
(comprising data such as the MessageContext field value, 
see FIG. 3C at 28b, some other Protocol Dependent data, 
see FIG. 3B at 38a and FIG. 3D at 38c, or a 
PhysicalAddress, see FIG. 3A at 34, to the host-based 
reply message frame generated under step L above). If 
there are no posted reply descriptors when the system/host 
driver 7ft 80 reads a respective Reply Post FIFO 77, 87, 
the host driver 70, 80 will receive some arbitrary value 
(such as the value FFFFFFFFb) indicating that there are 
no more reply descriptors to be read. 
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K. Each respective host driver 70, 80 then responds to the 
initiator/caller (such as an operating system, not shown 
for simplicity) appropriately. 

L. In the event a reply frame (72, 82) was needed during the 
process to respond to the initial I/O request (which 
generally occurs only in a very small fracLioo of the cases) 
and, thus, an available address was removed from the 
Reply Free buffer (78, 88) and a reply message generated 
and written to tbe allocated reply frame, the host driver 
(70, 80) returns the address lo the respective Reply Free 
FIFO buffer 78, 88, 

Referring back once more to FIGS. 3A and 3B to sum- 
marize the features depicted by HO. 4: The Address Reply 
mechanism (such as that explained above as step I. where 
tbe I/O status is not successful) requires an IOC 90 to 
remove an available SMF address from the Reply Free 
buffer (FIG. 4 at 78 or 88), build a reply message, DMA the 
reply message to the respective host driver 70, 80, as well as 
build a reply descriptor (FIG. 3A at 30) and place it on a 
respective Reply Post buffer (FIG. 4 at 77, 87). On the other 
hand, the much more efficient context reply mechanism of 
the invention (explained above as step H. where the I/O 
status is successful) reduces these PCI accesses, thus 
increasing performance, to a single write of a reply descrip- 
tor (such as any of those depicted in FIGS. 3B, 3C, and 3D 
at 35, 40, and 45) to the Reply Post buffer (FIG. 4 at 77, 87). 
This is accomplished by having the IOC write a single 
content field (of any designated length) shifted the appro- 
priate bits to accommodate an indication field (that can 
function to identify the general type of reply descriptor, see 
FIGS. 3B, 3C, and 3D at 36a, 366, and 36c) to a Reply Post 
buffer (FIG. 4 at 77, 87). See also, the data flow diagram 
labeled FIG. 5. 

Therefore, as one can readily appreciate that the novel 
context reply mechanism of the invention requires that a 
host driver do only a single PQ Read to retrieve tbe context 
and indication fields (such as are referenced at 38a-38c and 
36o-36c of reply descriptors 35, 40, 45, respectively) from 
a Reply Post buffer, and no PQ Write to post the Reply Free 
SMF address is needed in the majority of instances where no 
reply message frame is used when tbe I/O status is success- 
ful. Note that the figures label several queues specifically as 
FIFO (flrst-in-first-out), although they need not be that 
particular type of buffer. 

Turning to the data flow diagram labeled FIG. 5, identified 
(for reference only) along the left band side (see arrow 120) 
are blocks representing the various logically defined layers 
of an I/O system execution environment. Details of the I/O 
system data flow represented in FIG. 5 are set forth below 
in connection with reference numbers: 

101. An initiator/caller Operating System (OS) issues a 
request or command. 

102. An OSM (operating system module, or OS Specific 
Device Driver) — such as the two modules referenced in 
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is 
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30 



35 



40 



45 



50 



105. Tbe IOC posts tbe request message to tbe target 
DDM's event queue. 

106. The target DDM processes (or, at least attempts to 
process) the request 

107. After the target DDM processes and satisfies the 
request successfully (which occurs for the vast majority 
of request messages transmitted), the IOC generates a 
reply descriptor for that request. Note here thai, 
although not specifically illustrated in FIG. 5, for the 
small percentage of request messages that are not 
'processed without error' an available reply message 
frame address is removed from available message 
frame addresses residing in a buffer (e.g., Reply Free 
buffer at 78 or 68 in FIG. 4), a reply message is built 
by the IOC to include information concerning the fault, 
error; failure, etc., (ix., that which has not been met) 
and copied into tbe reply message frame. The IOC then 
generates a reply descriptor (with an address, or 
whereabouts, of the reply message frame, with bits 
shifted to accommodate an indication field). 

108. Tbe reply descriptor generated (whether it be an 
Address Reply or the more often encountered Context 
Reply, see FIGS. 3A-3D) is queued to a Reply Post 
buffer (such as those shown in FIG. 4 at 77, 87). 

109. The writing of the reply descriptor to a Reply Post 
buffer can be done in connection with some type of an 
alert signal, eg, a system interrupt, to the system/host 
driver that a reply descriptor is ready for reading. Tbe 
system driver receives the alert signal and reads the 
Reply Post buffer to get the reply descriptor informa- 
tion. Due to indication field 32 of the reply descriptor 
(see examples in FIGS. 3A-3D), it is readily apparent 
whether tbe descriptor is of an Address or Context reply 
type. If the descriptor is of the Address type, the 
associated reply message must be found and read. 

110. The system/host driver then correlates each specific 
reply response with an original, corresponding request 
to complete the response process. For example, the host 
driver can retrieve an address-pointer to the original I/O 
request by looking at a Context reply descriptor's 
context field (see 38a, 386, 38c in FIGS. 3B^3D) or 
looking at an I/O request identifier found in any reply 
message, if it was necessary to so generate a reply 
message (see FIG. 8B for an example format). 

111 . The host driver returns tbe I/O request to the initiator 
operating system. 

Since a host system generally communicates with an IOC 



FIG. 4 as host drivers 70, 80 — accepts the request and 55 through the use of System Interface registers, by way of 



translates it into a request message addressed to a target 
DDM. The OSM has the option to place a pointer 
(location indicator, such as a physical or virtual 
address) to the OS I/O request in the request message's 
TransactionContext field. 

103. The OSM (system/host driver e.g., the host drivers at 
70, 80 in FIG. 4) invokes the communication layer to 
deliver tbe request message. 

104. Tbe host driver queues tbe request message (can be 
done via mechanism such as that identified in I a O 
Specification as Messengerlnstance) by copying it into 
a message frame buffer residing on an IOC. 
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example only, FIG. 6 illustrates aa example System Inter- 
face Register Map 130 for this purpose. Access to registers 
can be provided as is customary in I/O architecture, via 
memory and/or I/O mapping. 

FIG. 7A illustrates yet another example of a request 
message format, namely a Coofig request message 140, for 
supporting configuration operations such as read/write. Tbe 
format of an example reply message to tbe FIG. 7A request, 
65 is represented at 150 in FIG. 7B. The Config request 
message 140, such as that in FIG. 7A, is used to access 
operational parameters supported by the IOC 
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Description of Fields Represented in the Example Config 
Reply Message of FIG. 7B 



[OCStAtua 


This field it used to return IOC supplied urformatioa rpecZAo to 




Configuration xequests In addition lo the function Independent 




valutt specified as shown is the Default Reply Message. 


rocst&ms 


Description 



IOC5TATUS_CONFIG_BAD_ACnON 

IOOTATUS_COHFIG_BAD_TY?E 

IOOTATUS_CONFIG_BAD_PAGE 

rOCSTXTUS_CONFIG_BAD_DATA 

IOCSTATUS_.CONHG_NO_DEFAUUTS 

IOCSTATUS_CONFlQ__CA>rT_OOMMrr 

Reserved 



The action ts not supported 

The configuration type Is not mpported 

The configuration page ia not supported 

Incofieci Acid setting within the configuration data 

Can not set defaults for this page 

Non-volaUlD memory vol available or error while 

writing persistent data lo non-volatile memory 

Function specific fields. 



FIGS. 8A and 86 depict an alternative SCSI request 
message format labeled 160 and corresponding error reply 
message format 170: SCSI Initiator 10 message represented 
in FIG. 8A is used to send a specific class of requests, 
namely, SCSI I/O requests to specific target devices. And 
according to the novel features of the invention, the SCSI IO 
Error reply message 170 in FIG. SB need only be generated 



-continued 



SOL Toe scatter gather Hat which identifies the memory 

location of the data for ibis 10. 

Description of Additional Fields Represented in the FIG. 8B 
Example Error Reply Message 



IOCLogLvfo 


An implementation specific value intended to supplement the 10 
Controller status. 

This field ia need to return IOC supplied information specific to 
SCSI IQ requests in addition to the function independent vahioa 
specified in FIG. 3F Default Reply Message. 


lOCSUtue 


lOCStatus examples 


Description 



IOCSTATUS^SCSLJIECOVEREDJERROR 

lCXSTATUS^CSt_JNVAUD_JBUS 

IQCSOTUSJCSIwWAlJD^ARGEnD 

I0CSTATUS^(SIJEV1CE_NOT_THERE 

lOCSEAJUS^CSUD^TX-OVERRUN 

IOCSTATUS^CSt_DA3A_UNDERRUN 

IOCSIXrUS_SCSL_ra_DATA_ERROR 

IOCSTATUS^CSLJ , R0rOOOU_ERROR 

IOCCTXTUS^(XUTASK_TERMr^ATED 

rcxsriva\}s_scsr_BUS_jiESBr 

lOCSTATUS^CSt.TASK^MOMT^AILED 
Reserved 



I/O operation completed successfully after retries 

Out of range Bos value in request message 

Out of range largo tID value in request message 

Selection time-cut or device does not exist 

SCSI device attempted lo transfer more data than 

the amount specified by the byte count 

SCSI device trans tared less data than the amount 

specified by the byte count 

I/O terminated because of unrecoverable bus parity 

CRC error 

I/O terminated because of unrecoverable bus 
protocol error 

1/0 terminated became of SCSI Task Management 
Request 

I/O terminated because of a Bus Reset uaretaled to 
a SCSI Task Management Request 
SCSI Task Management function failed 
Function dependent fields. 



and transmitted if the SCSI 10 request experiences any of a 
number of errors or failures during the process lo carry it out 
(e.g., an event occurs such that any one of a set of predefined 
conditions is not met) and the 10 request is, therefore, not 
completed. 

Description of Fields Represented in the Example SCSI 10 
Request Message of FIG. 6A 



While certain representative embodiments and details 
have been shown merely for the purpose of illustrating the 
invention, those skilled in the art will readily appreciate that 
various modifications may be made without departing from 
the novel teachings or scope of this invention. Accordingly, 
all such modifications are intended lo be included within the 
scope of this invention as defined in the following claims. 
Although the commonly employed preamble phrase "com- 
prising the steps or may be used herein, or hereafter, in a 
method claim, the Applicants in no way intends to invoice 35 
U.S.C section 112 H6. Furthermore, in any claim that is filed 
hereafter, any means-plus-function clauses used, or later 
found to be present, are intended to cover the structures 
described herein as performing the recited function and not 
only structural equivalents but also equivalent structures. 
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Target ID The target device identification number. 

Bus The SCSI bus number that the target device exists on. 

CDBlxngth Number of used bytes in CDB field. 

MessageFtegs All reserved bits must have a value of 0. 

LUN The Logical Unit Number or the target device. 

CDB SCSI Command Descriptor Block. 
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What is claimed is: 

1. A reply descriptor for transmission over an I/O message 
passing medium in response to a corresponding request 
message, comprising: 

at least one indication field that identifies type of the reply 5 
descriptor, and a content field; and 

whereby a reply message is generated only if at least one 
predefined condition is not met and said content field 
comprises information of said reply message's storage 
location, if so generated. 10 

2. The reply descriptor of claim 1 wherein: 

the message passing medium comprises a bus operational 
with a hardware interface type selected from the group 
consisting of SCSI (Sraill Computer System Interface), 3J 
Fibre Channel, PCI (Peripheral Component 
Interconnect), PCI-X, ISA (Industry Standard 
Architecture), InfiniBand, IDE (Integrated Drive 
Electronics), USB (Universal Serial Bus), RS-232, 
EISA (Extended ISA), Local Bus, and Micro Channel; ^ 
and 

the message passing medium utilizes a communications 
protocol selected from the group consisting of SCSI, 
ATM (Asynchronous Transfer Mode), IPI (Intelligent 
Peripheral Interface), HiPPI (High Performance Paral- 25 
lei Interface), IP (Interact Protocol), InfiniBand, SSA 
(Serial Storage Architecture), and IEEE P1394. 

3. The reply descriptor of claim 1 wherein: upon the 
writing of the reply descriptor to a reply-post buffer, an 
interrupt is transmitted for a host-based driver to read the 30 
reply descriptor; and once so read, said host-based driver 
correlates the reply descriptor with the request message and 
sends a notification message to an originaling-callcr. 

4. The reply descriptor of claim 1 wherein: 

said indication field comprises an address bit; 35 
if each said predefined condition is met, said indication 
field further comprises a type field, and said content 
field comprises data copied from and unique, to the 
request message as generated by a host-based driver; 
but 40 
if said reply message is so generated, said reply message 
comprises data regarding said at least one predefined 
condition not met 

5. The reply descriptor of claim 4 wherein: 

if each said predefined condition is met, said content field 45 
further comprises a receiving port identifier, and said 
data unique to the request message comprises an iden- 
tifier selected from the group consisting of: an address 
to a storage space in a memory, an index value to a 
table, an index value to a list, an index value to a 50 
register, an index value to a stack, an index value to an 
array, and content-data associated with a hardware 
assisted CAM; and 

said reply-post buffer is a FIFO (First-In-First-Out) type 
butler. 55 

6. A reply descriptor for transmission over an I/O message 
passing medium in response to a corresponding request 
message, comprising: 

at least one indication field comprising an address bit, and w 
a content field; 

whereby a reply message is generated only if at least one 
predefined condition is not met and said content field 
comprises information of said reply message's storage 
location, if so generated; £5 

wherein each said predefined condition is met: said indi- 
cation field further comprises a type field, said content 
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field comprises data copied from and unique to the 
request message as generated by a host-based driver, 
said data unique to the request message comprises a 
host-specified index value; 
an alert signal for said host-based driver is transmitted 
upon the writing of both the reply descriptor and a 
second reply descriptor to a reply-post buffer, said 
second reply descriptor comprising a second content 
field having second data copied from a second request 
message, and once said reply descriptors have been 
read by said host-based driver, said host-based driver 
correlates each said reply descriptor with a respective 
request message and notifies an originating-caller of 
completion of both of said request messages, 
7. The reply descriptor of claim 1 wherein: said at least 
one predefined condition is not met and said content field 
comprises said information, said information to comprise an 
address to an available reply frame buffer located in a host 
memory; and said address is one from a plurality of 
addresses, each of which identifies a location of a corre- 
sponding reply frame buffer. 

6. The reply descriptor of claim 7 wherein said at least one 
predefined condition is not met because execution of at least 
one command included in the request message was not 
completed, said corresponding reply frame buffers reside, in 
said host memory, and said plurality of addresses resides 00 
a reply-free FIFO buffer. 

9. The reply descriptor of claim 6 wherein: 
once said address to said available reply frame buffer is 

removed from said reply-free FIFO buffer, said reply 
message is generated by an I/O controller (IOC) and 
copied into said available reply frame buffer, and 
the reply descriptor is written to a reply-post buffer for a 
host-based driver to read. 

10. The reply descriptor of claim 1 wherein: 
the request message comprises at least one command; and 
said at least one predefined condition is not met upon the 

occurrence of an event selected from the group con- 
sisting of: execution of said command is not completed, 
execution of said command is not completed after a 
retry, said command is made at an improper time, an 
allotted time for execution of said command is 
exceeded, unfai r rrssfi T 1 data transfer of any portion of 
the request message, quantity of data transferred 
exceeds byte count specifications, quantity of data 
transferred is less-than byte count specifications, pro- 
cessor resources are insufficient to execute said 
command, at least one field of the request message 
comprises invalid data, at least one value from the 
request message is out of range, any data transferred is 
insufficient to execute said command, hardware inter- 
face of the message passing medium is incompatible 
with a target device, communications protocol utilized 
by the message passing medium is incompatible with a 
target device, an unrecoverable bus parity error has 
occurred, a task management function has failed, a host 
processor aborts the request message, and a target 
device node bas logged-off. 

11. A method of responding over an I/O message passing 
medium, to a request message, the method comprising the 
steps of 

generating a reply message to the request message only if 

at least one predefined condition is not met; 
generating a reply descriptor having at least one indica- 
tion field that identifies type of said reply descriptor, 
and a content field; whereby said content field com- 
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prises information of said reply message's storage descriptor further comprises writing said content field to a 

location if said reply message is so generated. reply-post buffer, said content field to further comprise a 

12. The method of claim 11 wherein: if each said pre* receiving port identifier and a request-initiator identifier; and 
defined condition is mei F said content field to comprise data further comprising the step of transmitting a system interrupt 
copied from the request message rather than said storage 5 f or a host-based driver to read said reply descriptor, 
location information. 18. The method of claim 17 further comprising the steps 

13. The method of claim 12 wherein: of: re ading said reply descriptor; correlating a request mes- 
the message passing medium comprises a bus operational sage identifier of said reply descriptor with the request 

with a hardware interface type selected from the group message; and notifying an originating-caller to confirm 
consisting of SCSI (Small Computer System Interface), w completion of the request message. 
Fibre Channel, PCI (Peripheral Component 19. Tbe mcthal of cUim 17 wherein said step of gener- 
Inlerconncct), PCI-X, ISA (Industry Standard aling ^ reply descriptor is performed with an I/O con- 
Architecture), InfiniBand, IDE integrated Drive troner(IOC); and said step of transmitting a system interrupt 
mertronics), USB (Universal Serial Bus), RS-232, fc ^ ^ l0C ; and further comprising a reply 
^(Extended ISA). Ix>cal Bus, and Micro Channel; « qu £ e rcgisler ]ocated m an 10C memory, said register to 

comprise said reply-post buffer and a reply free buffer oo 
the message passing medium utilizes a communications which a p ]ura]i( v 0 f addresses, each of which identifies a 

SCle t ted 6 ° m J he f™S ^f^f,? 051 ; location of a corresponding reply frame buffer, reside. 
AIM (Asynchronous WerMoAO, IPI GntelhgMt 20. The method of claim 12 whereto said .1 least one 
Peripheral Interface) HiPPI (fflgh Per&nn^ce Panl- ^ h nQl ^ &aid ste of ^ 

U.H» method of claim 12 wherein said indication field field «? 6 tom ^ A fidd , ,0 

comprises an address bit, and further comprising the steps r ""V™ 8 , <** information netadng an address to an avafl- 
of- 25 »ble reply frame buffer located in a host memory, said 

'if each said predefined condition is met, generating said ^dress having been taken from a reply-fxce on which a 
indicaUon field to further comprise a type field and plurality of addresses also reside; and further comprising the 
generating said data copied to comprise data unique to ste P generating said reply message with said IOC and 
the request message; but 3Q copying said reply message into said available reply frame 

said at least one predefined condition is not met, gener- buffer, 
ating said reply message to comprise data regarding 21 - A computer executable program code on a computer 
said at least one predefined condition not met. readable storage medium, the program code comprising: 

15. The method of claim 14 further comprising the steps a first program sub-code for generating a reply message to 
ofc 35 a corresponding I/O request message only if at least one 

upon the writing of said reply descriptor to a reply-post predefined condition is not met; and 

buffer, transmitting an alert signal for said host-based first program sub-code comprising instructions for 

driver to read said reply descriptor; and generating a reply descriptor having at least one iodi- 

once so read, correlating said reply descriptor with the cation field and a content field that comprises informa- 

request message and notifying an originating-caller of 40 tf on 0 f sa id reply message's storage location if said 
a completion results. r&ply message is so generated, but said content field to 

16. The method of claim 12 further comprising the steps comprise data copied from said I/O request message if 
of initially receiving an I/O request comprising at least one Mch ^ predefined condition is met 

command from an operating system, and generating the 22. The program code of claim 21 wherein said instruc- 
request message to include said one command; and wherein 45 ^ for gencratmg said rep i y descriptor further comprise 
said at least one predefined condition is not met upon instructions for writing said content field to a reply-post 
occurrence of an event selected from the group consisting buffi ^ ^ fnxthct comprising: 

of: execution of said command is not completed, execution , . , - • f 

of said command is not completed after a retry, said com- a second sub-code for transmjtUng a system mterrupt over 
j . j 4 . ^ * 5, 7 ™ an I/O message passing medium for a host-based driver 

mand is made at an improper time, an allotted time for so . ' , \ . 7* , M 

execution of said command is exceeded, unsuccessful data to read said reply descriptor; 

transfer of any portion of the request message, quantity of a third sub-code for reading said reply descriptor; and 
data transferred exceeds byte count specifications, quantity a fourth sub-code for correlating said reply descriptor 
of data transferred is less-tban byte count specifications, with said corresponding I/O request message and noti- 

processor resources are insufficient to execute said 55 fying an originating-caller of a completion results, 
command, at least one field of the request message com- 23. The program code of claim 22 wherein each said 
prises invalid data, at least one value from the request predefined condition is met and said content field comprises 
message is out of range, any data transferred is insufficient data copied from said I/O request message including an 
to execute said command, hardware interface of the message identifier selected from the group consisting of: an address 
passing medium is incompatible with a target device, com- 60 to a storage space in a memory, an index value to a table, an 
munications protocol utilized by the message passing index value to a list, an index value to a register, an index 
medium is in compatible with a target device, an unrecov- value to a slack, an index value to an array, and content-data 
erable bus parity error bas occurred, a task management associated with a hardware assisted CAM; said third sub- 
function has failed, a host processor aborts the request code comprises instructions for reading into a host-based 
message, and a target device node has logged -off. 65 memory; and said fourth program sub-code comprises 

17. The method of claim 12 wherein said predefined instructions for correlating said request message identifier of 
condition is met, and said step of generating said reply said reply descriptor with the I/O request message. 
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24. The program code of claim 22 wherein said at least 
one predefined condition is not met because execution of at 
least one command included in said I/O request message 
was not completed and said content field comprises said 
information, said information to comprise an address to an 
available reply frame buffer bcated io a host memory; and 
said address is one from a plurality of addresses, each of 
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which identifies a location of a corresponding reply frame 
buffer residing in said host memory. 

25. The program code of claim 24 wherein said third 
sub-code comprises instructions for reading said reply 
descriptor from a reply-post buffer. 
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